NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/misc-part1/2697

Internet Message Format | 1996-08-05 | 5.5 KB

Path: EU.net!sun4nl!xs4all!usenet
From: [e-mail] (Jeroen T. Vermeulen)
Newsgroups: comp.sys.amiga.misc
Subject: Re: OS features
Date: Tue, 23 Jan 96 01:16:15
Organization: Leiden University, Mathematics & Computer Science, The Netherlands
Message-ID: <[e-mail]>
References: <[e-mail]> <4dh2dm$[e-mail]> <[e-mail]> <4do01q$[e-mail]> <[e-mail]> <4dtg0e$[e-mail]>
NNTP-Posting-Host: asd07-10.dial.xs4all.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-NewsSoftware: GRn 2.1 Feb 19, 1994


In article <4dtg0e$[e-mail]> [e-mail] (Michael van Elst) writes:

[ Why keep PUBLIC pages locked in real mem? ]

> >I think it's because Forbid()/Permit() is still used in a lot of places where
> >the OS should have defined a separate semaphore (and probably implemented
> >deadlock detection and resolution as well).  So this memory is *more likely* to
> >page-fault during Forbid().
>
> Actually the problem is that the flag MEMF_PUBLIC was never used for
> anything and wasn't thought out well.

AFAIK it is commonly used (and used properly) by applications, and the
distinction is relevant for VMM.  If the flag really doesn't matter, then this
can't be the problem at all.

I just looked in the VMM docs (should have done that sooner), and they say that
the problem is that stuff like I/O requests and the like mustn't be swapped out.
What is probably meant is that deadlocks must be prevented, where memory is
swapped out that needs to be present in real mem for the swap mechanism as a
whole to work.  Of course the task list etc. must also be kept consistent during
Forbid().


> >[1] implement a special driver for the swap device as a single-threaded library,
> >more or less like other OS's do (boo!), or
>
> Which can't be single-threaded because the disk driver can use arbitrary
> tasks. That's no BIOS.

It would have to lock, of course.  With `single-threaded' I mean here that only
one instance of the code could be active at any time (as if it were a task), but
no actual context switch is made (as if it were a library).

Hey, I didn't say it was a *pretty* solution!


> >[2] make a radical change:  Design around the problem for the new PPC OS so the
> >problem is limited to the 68k emulator (compatibility vs VM/MP--past vs future!)
>
> The radical change is that software has to declare wether data has to
> be locked in memory and it has to declare who will get access to the
> data.

You mean separate flag bits for "swappable" and "sharable"?  AFAICS the only
pools that had to be locked in memory would be:

 - Private memory allocated by the VM subsystem
 - Global shared public mem (eg. public process list)
 - Memory shared between any task and the VM subsystem + VM device driver

Am I missing another useful application?


> Of course there will be unprotected memory, heuristics for old programs
> (like the VMM database) and automatisms that let shared libraries handle
> private data without special preparations.

Libraries aren't a problem in themselves, because they never leave the caller's
context unless they're programmed to.  There is however the problem that you
can't always tell who you're going to share your memory with (eg. when calling
the dos.library functions).  This problem can be solved if all type information
is known at the layer that passes the memory block on to the unexpected task.


> >The easiest change would perhaps be, to have multiple public-memory pools for
> >different groups of communicating processes,

> >each guarded by a semaphore, and
> >change the meaning of the current Forbid() calls to "Obtain non-shared (write)
> >access to all virtual public memory spaces accessible to me".
>
> This unfortunately does not work.

Why not?  As the set of "attempted" semaphores cannot change within a Forbid()
section, the result is a trivial two-phase locking mechanism where no deadlocks
can occur.  Of course the process list etc. would have to be virtualized so each
process sees its own version which does not change in the meantime.  Most of the
work could probably be deferred until a Forbid() call is actually made.

As all other memory is protected, I think this could work even in multiprocessor
systems.  Of course it would hurt performance at first, but given a faster CPU
to do this work (in native code) and an improved OS design it could be practical
enough to allow existing applications a dignified retirement period.


>                               But Forbid() isn't really useful
> either in most situations. New programs really must use other
> arbitration mechanisms. That's another reason why I want Forbid()
> and Disable() to be trapped. A multiprocessor configuration will
> then be the end of the "traditional" use of Forbid().

Of course, but it must be supported for existing software.  And with the scheme
outlined above I think it can be, even in such multiprocessor configurations.


>                                 Michael van Elst
>
> Internet: [e-mail]
>                                 "A potential Snark may lurk in every tree."

--
============================================================================
#  Jeroen T. Vermeulen   \"How are we doing kid?"/   Yes, we use Amigas.   #
#---  [e-mail]    ---\"Oh, same as always."/--         ...          --#
#[e-mail] \ "That bad, huh?"  /  Got a problem with that? #

MicroSoft.  Where Do You Want To Go Today?  ... We'll have you there in a decade